2019 开源安全报告：开发者安全技能短板明显，热门项目成漏洞重灾区！

近年来，开源软件的使用范围正在不断扩大，“拥抱开源”似乎也成了一种企业间的普遍趋势。特别是在 2018 年，科技巨头纷纷加注——微软以 75 亿美元收购了 GitHub；IBM 以 340 亿美元拿下 RedHat，开源软件正在成为现代企业的基础。

与此同时，暴露于安全漏洞的风险也在逐步增长，开源环境的安全问题开始受到越来越多的关注。而漏洞数量的增幅与开发者自身技能与安全意识提升速度间的断层，也成了一大不容忽视的问题。

作者 | 仲培艺

出品 | CSDN（ID：CSDNnews）

为了更好地了解开源的安全现状，以及相对应的改进手段，针对开源项目提供安全服务的公司 Snyk 对一系列数据进行了统计分析，并于近日发布了《2019 年度开源安全现状调查报告》，其数据来源包括：

• 由 Snyk 发起的一项调查，该调查覆盖了 500 多名开源项目的维护者和用户；

• Snyk 漏洞数据库的内部数据，以及由 Snyk 监控和保护的数十万个项目；

• 通过研究各供应商发布的外部资源，以及通过扫描数百万个公开的 GitHub 仓库和包收集到的数据。

开源项目采用率和漏洞数量“比翼”齐增

Java 包翻番，npm 约增 25 万新包

回顾 2018，我们不难发现在各语言生态系统中，越来越多的开源库被编入索引，且呈现出爆炸式增长。2017-2018 年，索引包增长情况如下：

• Maven Central：102%

• PyPI：40%

• npm：37%

• NuGet：26%

• RubyGems：5.6%

据报告显示，开源项目的采用率正在加速增长。仅 2018 年间，Java 包便翻了一番，npm 亦增加了大约 25 万个新包。

Python 下载翻倍，JavaScript 包下载量高达 3170 亿个

开源软件的消费也在飞速发展。从 PyPI 下载的 Python 包是以前的两倍，从 npm 下载的 JavaScript 包更是达到了惊人的 3170 亿个。

PyPI 在 2018 年拥有超过 140 亿的下载量，较之 2017 年的 63 亿次已然翻了一番。

PyPI 包在 2018 年的下载次数

注：如上图所示，年中下载数量的激增是由于 PyPI 统计数据收集服务 linehaul 的一个故障，因此漏掉了 8 月之前了大约一半的下载记录。据推测，2018 年的下载量为 140 亿次，但实际数量可能要更多。

npm 注册表是整个 JavaScript 生态系统的核心。在过去的几年里，其下载数量和软件包数量一直在稳步增长。仅 2018 年 12 月一个月的下载量就超过了 300 亿次，而 2018 年全年的下载量更是惊破 3170 亿次。

npm 包在 2018 年的下载次数

随着软件包数量的增长，它们的漏洞也在增加。Linux 基金会在去年报告称，开源贡献者已经提交了超过 310 亿行代码。然而，随着大量采用，随之而来的是巨大的压力和风险，任何拥有、维护或使用此代码的人都需要承担起降低风险的责任。2017 年，CVE 报告了超过 14000 个漏洞，打破了单年内的最高记录。而这一数据在去年再创新高，披露了超过 16000 个漏洞。

已知漏洞数增幅明显，处理任务日趋紧迫

漏洞就是漏洞，不管是否已知。两者之间的关键区别在于攻击者意识到这个漏洞并试图利用它的“可能性”。因此，对漏洞的认识越深入，对其处理的需求就越迫切。

已知的漏洞可能具有与之关联的 CVE ID，也可能只是在网上披露或存储在开放数据库中。这些都是应该优先消除的已知漏洞类型，因为它们受到攻击的几率更高。再之后就应该考虑在封闭的漏洞数据库中捕获的漏洞，甚至是在暗网中共享的漏洞。

应用程序库漏洞在两年内增加了 88%，npm 及 Maven Central 数据突出

• 两年内应用程序的漏洞数量增长了 88％；

• 2018 年，npm 的漏洞数量增长了 47％；据 Maven Central 和 PHP Packagist 披露的数据显示，其漏洞数量涨幅分别为 27％ 和 56％；

• 较之 2017 年，2018 年在 RHEL、Debian 和 Ubuntu 中追踪发现的漏洞数量增加了 4 倍多

值得特别关注的是，自 2014 年以来，Synk 的 npm 数据库和 Maven Central 数据库中的漏洞数量分别增长了 954% 和 346%。

高危漏洞有所减少，但在整体漏洞中仍占最大份额

对比查看了过去三年在所有语言生态系统中公开的应用程序库的漏洞严重程度时发现，与前一年相比，2018 年的高危漏洞数量有所减少。

此外，还有一个有趣的发现，那就是与 2016 年相比，2017 年和 2018 年的一个共同点是，高危漏洞多于中危漏洞或低危漏洞。

Zip Slip 漏洞

Zip Slip是一个广泛存在的关键存档提取（critical archive extraction）漏洞，该漏洞允许攻击者在系统中任意写文件，尤其是会导致远程命令执行。Snyk安全团队的研究人员6月5日发现并公布了该漏洞的细节，该漏洞影响上千个工程项目，其中一些工程来自HP、亚马逊、Apache、Pivotal等。

没有 CVE 编号的漏洞

当新的漏洞通过国家漏洞数据库（National vulnerability Database, NVD)）或其他公共 CVE 存储库公开时，安全团队通常会跟踪并应对这些漏洞。然而，很多安全漏洞是在非官方渠道中发现和修复的，比如通过问题跟踪器中维护人员和用户之间的非正式通信。

安全现状与开发者专业技能不对等，漏洞解决难度升级

谁该对开源软件的安全性负责？据报告显示：

• 81％ 的用户认为开发者负责开源软件的安全性

• 68％ 的用户认为开发者应该对他们提供的 Docker 容器镜像负安全责任

• 只有 30% 的开源软件维护者认为自己具有高安全性意识

谁该对开源软件的安全性负责

开发人员总被赋予安全保障的重任，但事实上他们并未准备好。

开源维护者想要安全，但是他们当中有七成表示自身缺乏相应技能。

开源维护者表示，他们的安全知识正在提高，但还不够高。据调查显示，大多数用户将他们的安全知识列为中等水平，平均 6.6 分（满分 10 分） 63%，而去年这一档的比例为 56%。

开发者对自身安全意识的认知情况

此外，还有四分之一的开源维护者表示不会去审计他们的代码库。去年，44% 的受访者表示他们从未进行过安全审计，而今年，这个数字倒是降了很多，26% 的用户表示他们没有审计源代码的习惯。

同时报告中还谈到了安全测试环节的缺失：

• 37％ 的开源开发者在持续集成（CI）期间没有实施任何类型的安全测试；54％ 的开发者没有对 Docker 镜像进行任何安全测试

• 从漏洞添加至开源软件包到修复漏洞的时间中位数超过 2 年

持续集成期间的安全测试情况

Docker 镜像成漏洞重灾区，Node 环境下数量最多

Docker 镜像几乎总是在带来巨大价值的同时带来已知漏洞：

• 十大最流行的默认 Docker 镜像中，每一个都包含至少 30 个易受攻击的系统库

• 20% 的镜像可以通过简单地重建 Docker 镜像来修复漏洞；44% 经过扫描的 Docker 镜像可以通过更新其基本镜像标记（image tag）来修复已知漏洞。如果你意识到这一点，修复起来会很容易。

十大流行 Docker 镜像的漏洞数量

Linux 操作系统的漏洞数量在持续增长

系统库中的紧急漏洞和高危漏洞数量对比

npm 中的 ReDoS 漏洞激增 143%，XSS 继续增长

正则表达式拒绝服务（ReDoS）

众所周知，Node.js 运行时有许多优点，但有一点需要注意的就是“单线程事件循环”，如果没有正确使用，就极有可能成为其最薄弱的环节。这一情况发生的频率比大家想象的要高。

ReDoS 攻击利用了一些正则表达式模式可能导致的非线性最坏情况的复杂性漏洞。对于单线程 runtime 而言，这可能是毁灭性的，这就是为什么 Node.js 会受到这种漏洞的严重影响。

调查发现，在过去三年里，ReDoS 漏洞暴露的数量越来越多，仅 2018 年就激增了 143%：

XSS 漏洞

跨站点脚本攻击（XSS）已经成为 Web 应用程序日益增长的痛点，2018 年，在  Snyk 一直监控的所有生态系统中，XSS 漏洞呈增长趋势。

开源库中的 XSS 漏洞仍然在增加，尽管它已经成为 OWASP（一个组织，全称开放式 Web 应用程序安全项目）这 15 多年来关注的首要问题。

在这些生态系统中，我们发现 npm 中的 XSS 漏洞最多，总共暴露了 225 个；其次是 Maven 中央存储库，有 167 个；PyPI 共 163 个跨站点脚本漏洞。2018 年，PHP Packagist 生态系统披露的 XSS 漏洞最多，共 56 个，其次是 npm（54 个）和 Maven Central（29 个）。

78% 的漏洞是在间接依赖中发现的，这使得修复非常复杂

很难想象在没有任何开源依赖的情况下编写软件的日子。管理项目的依赖关系是一项重要的任务，需要尽职调查来正确跟踪所依赖的库。毕竟，你正在部署的应用程序捆绑了你的代码和依赖项。

npm、Maven 和 Ruby 中的大多数依赖项都是间接依赖项，间接依赖项中的漏洞占总体漏洞的 78%。

风险和影响

只有三分之一的开发人员能够在一天或更短的时间内解决高危或关键漏洞。

在 GitHub 今年发布的 GitHub Octoverse 报告中，安全性是最受欢迎的项目集成应用程序类别。这里引用下 Gartner 在最近一份应用程序安全报告中的一段话，该报告讲到了组织在应用程序生命周期中尽早展开安全测试的必要性：

企业应定期使用 SCA 工具对包含软件资产（例如版本控制和配置管理系统）的存储库进行审计，以确保企业开发和/或使用的软件符合安全和法律标准、规则和法规。应用程序开发人员应该能够访问 SCA 工具来检查他们计划使用的组件。——Mark Horvath, Hype Cycle For Application Security 2018, Gartner

据此次报告显示，将近一半（43%）的受访者至少有 20 个直接依赖项，这增加了监视通过这些库引入的开源漏洞的必要性。

我们使用开源软件的次数越多，就会积累越多的风险，因为我们包含了其他人的代码，这些代码现在或将来可能包含漏洞。此外，风险不仅和代码的安全性有关，还关乎所采用代码的许可遵从，以及该代码是否违反了开源许可本身。

为了更好的开源环境

应用程序组合非常复杂。作为操作系统维护者和开发人员，可以采取一些行动来提高您所拥有和参与的项目的安全性。

开源维护者

• 提供安全的代码版本，并向使用者提供一种通信策略，以便积极地影响其他项目和应用程序，最终使自己的项目也很可能受益；

• 如果可能的话，与同行一起进行安全代码评审，并遵循安全代码最佳实践。将安全性考虑作为代码评审检查指标的一部分，并对评审人员进行培训，以便他们知道应该留意什么；

• 定期检查代码库中的漏洞；

• 明确定义一个简单的流程，用于负责任的漏洞披露；

• 为团队提供对开发、CI，甚至创建 pull 请求时的安全问题的洞察力，以消除所有进入项目漏洞代码的机会。

开源开发者

作为开源组件的使用者，您有责任充分理解项目使用的直接和间接依赖项，包括依赖项树中可能存在的任何安全缺陷：

• 定期使用一种工具来审计代码库，该工具可以自动检测第三方依赖项中的漏洞，为团队提供修复建议，并监控项目的依赖项（即使在项目部署之后）；

• 如果您正在报告安全漏洞，请遵循负责任的披露策略，以确保您不会将用户置于危险境地。如果你不确定如何做到这一点，可以考虑向一家与你合作的安全公司披露；

• 订阅开源依赖项的安全通信通道（如果有的话），这样就可以在报告时了解任何潜在的漏洞。
  

另附完整报告下载地址：https://bit.ly/SoOSS2019

其他参考链接：https://snyk.io/opensourcesecurity-2019/

【完】

---

---

 热 文 推 荐 

System.out.println("点个好看吧！");
console.log("点个好看吧！");
print("点个好看吧！");
printf("点个好看吧！\n");
cout << "点个好看吧！" << endl;
Console.WriteLine("点个好看吧！");
Response.Write("点个好看吧！");
alert("点个好看吧！")
echo "点个好看吧！"

点击阅读原文，输入关键词，即可搜索您想要的 CSDN 文章。

喜欢就点击“好看”吧！